Computing devices achieve data security in part by performing a variety of cryptographic operations on data objects. Cryptographic operations typically use an encryption key, which may be either a secret key for a symmetric cryptographic operation or a public key for an asymmetric cryptographic operation. In order for a symmetric cryptographic operation to maintain security, the secret key should be kept secret.
A variety of algorithmic and non-algorithmic techniques may be used to insure the privacy of the secret key. Algorithmic techniques employ mathematical operations to transform a secret plaintext key into a ciphertext key. The ciphertext key may then be publicized without revealing the secret key from which it is formed. Commonly used cryptographic algorithms include: AES, DES, Triple DES, Blowfish, Serpent Twofish, and numerous others.
Non-algorithmic techniques employ design, physical features, architecture, operational rules, and the like to keep the likelihood that a secret key will be discovered as low as possible. Thus, restricting human or electronic access to a device which has a secret key reduces the likelihood of the secret key being discovered. Likewise, a system which keeps a secret key for only a short time has stronger security than one which attempts to maintain the secrecy of a key for a long time. And, a system which reuses a secret key to encrypt different data objects less often has stronger security than one which reuses the secret key more often.
Non-algorithmic techniques are also conventionally used to promote trust in the algorithmic techniques. Devices concerned with data security may use a secure processing device, such as a secure microprocessor or the like, which includes physical and logical features to provide a secure execution environment (SEE). The SEE, also called a trusted platform, security zone, and the like, may include software and/or hardware features which promote a high level of trust in the cryptographic operations the device may undertake, making the security features of the device nearly immune to malicious software that the device may accidentally or intentionally execute from time to time.
One feature conventionally included in a SEE is a permanent, or at least long-lived, secret key. The long-lived secret key desirably survives power cycling and resets, and is inaccessible to malicious software. Often, this long-lived key is cryptographically unique to the device in which it is stored. Thus, by using this long-lived key, data and software may be bound to the specific device where the data and software reside.
A conventional SEE also includes a random number generator for generating new keys when desired for use in cryptographic operations. In order to promote data security, many independent secret keys are desirably used for cryptographic operations on many different data objects rather than reusing a smaller number of secret keys. While the data objects may be publicized after encryption, the secret keys should be saved for subsequent decryption operations, and they should be kept secret. One conventional way to maintain the privacy is to save the keys in a secure memory device under the control of a SEE. Another conventional way is to encrypt them using the long-lived secret key for storage in unsecured memory, then retrieve them to the SEE and decrypt them when needed.
Both of these conventional approaches to managing secret keys pose problems. Memory under the control of a SEE is usually at a premium because it becomes more costly and difficult to maintain trust over larger amounts of memory. Thus, when device applications require the use of a high capacity key magazine capable of holding a vast number of independent secret keys, an insufficient amount of such memory will be available. Such device applications include secure high-capacity routers and servers capable of simultaneously supporting a vast number of communication sessions or other data object domains for a vast number of clients. Likewise, when device applications need scalability to support both a low-capacity key magazine and a high-capacity key magazine, reliance upon memory under the control of a SEE for storing secret keys limits such scalability.
But using a long-lived secret key to encrypt a data object, whether the object is payload data or a secret payload key used to encrypt the payload data, poses its own security concerns. The long-lived nature of this secret key poses non-algorithmic security risks. Its repeated use is desirably minimized. And, to compensate for the non-algorithmic security concerns associated with managing a long-lived secret key, it is desirably used only in connection with cryptographically strong algorithms. Stronger encryption algorithms are characterized by including tags and other features that insure authentication and integrity in addition to privacy or confidentiality. But stronger cryptographic algorithms typically require more processing time than weaker cryptographic algorithms. Accordingly, when a device repeatedly uses a long-lived secret key to encrypt and decrypt a vast number of payload keys, performance suffers from the use of stronger cryptographic algorithms and security suffers from repeated use of long-lived keys.